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is  report  covers  the  procedures  required  to  protect  critical 
phases  of  the  design,  development,  and  certification  of  a secure 
Multics.  Involved  is  protection  of  the  security  kernel  software 
from  unauthorized  alteration  or  sabotage.  The  facilities  of 
the  Government  Information  Security  Program,  are  applied.  The 
program  includes  protection  of  a security  kernel  for  Multics  and  a 
security  kernel  for  the  Secure  Communications  Processor,  w 
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Because  of  funding  limitations,  the  Air  Force  terminated  tne 
effort  which  this  document  describes  before  the  effort  reached 
its  logical  conclusion.  This  report  is  incomplete  but  was 
published  in  the  interest  of  capturing  and  disseminating  th 
computer  security  technology  that  was  available  when  tne  effor 
was  terminated. 
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SECTION  1 


Introduction 


1.1  Purpose 


Tnis  report  presents  a set  of  procedures  intended  to  ensure  tne 
security  and  integrity  of  tne  final  Operational  Prototype  Secure 
Multics  Demonstration  Systenr.  produced  under  Project  Guardian. 
The  report  first  presents  a brief  bacKground  of  the  goals  of  tne 
project  and  tnen  considers  tne  unusual  security  and  integrity 
problems  associated  with  this  development.  The  tnreats  to  be 
countered  are  discussed  and  finally,  a set  of  operating 
procedures  are  presented.  Tne  problem  addressed  by  these 
procedures  is  essentially  that  of  a trade-off  between  tne  need 
and  desire  for  absolute  integrity  of  tne  resulting  system  and  the 
costs  and  operational  difficulties  encountered  in  providing  the 
desired  level  of  integrity. 


1.2  EacKground 

Project  Guardian  is  part  of  a coordinated  effort  to  develoo  tne 
technology  required  to  support  secure  multilevel  computing.  The 
pr inary  goal  of  the  project  is  development  and  demonstration  of  a 
multiuser  resource  snaring  system  tnat  is  caoable  of  being 
certified  for  military  use.  The  system  must  provide  secure 
service  for  several  levels  of  classified  information  beina 
concurrently  operated  upon  by  users  with  several  different  levels 
of  clearances. 


Tne  military  has  developed  and  placed  in  use  effective  means  for 
imolementing , verifying,  and  certifying  physical,  commun ica tion , 
and  personnel  security.  Tne  problem  of  providina  an  equivalent 
level  of  confidence  in  computer  system  access  controls  remains 
unsolved.  A computer  system  witn  a verifiable  and  certifiable 
secure  operating  system  is  needed  to  complete  tne  provision  of 
secure  computing  services.  This  problem  is  being  addressed  oy 
Project  Guardian. 

Tne  method  oeing  used  is  to  develop  a security  Kernel  for  tne 
operating  system  of  a large  general  puroose  resource  sharing 
system  and  a security  Kernel  for  tne  communications  processor 
tnat  serves  the  large  system.  The  security  Kernel  has  the 
responsibility  of  enforcing  the  access  rules  of  the  CoD 
Information  security  Program.  Tne  design  of  tne  security  Kernel 
isolates,  in  one  area  of  tne  system,  all  of  the  mechanisms 
required  to  ensure  that  the  security  rules  are  rigidly  enforced. 
Ey  isolating  only  security  related  functions  in  tne  Kernel,  tne 
size  and  complexity  of  tne  Kernel  code  is  reduced  to  the  point 
tnat  formal  metnods  of  proof  of  correctness  can  be  aoolied. 
Project  Guardian  is  engaged  in  the  development  of  such  Kernels 
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for  the  Multics  operating  syste;Ti  and  for  the  front-end  processor 
that  connects  l-iultics  to  co.nmunications  lines. 

The  kernel  design  is  based  upon  a .ma  thematic  a 1 model  of  a secure 
system.  Formal  proofs  are  used  to  demonstrate  tnat  the  kernel, 
as  coded  in  the  system  development  language,  does  indeed  conform 
to  the  requirements  of  the  moael.  Conforming  means  tnat  the 
kernel  code  performs  precisely  as  tne  model  indicates. 

A formal  process  of  verification  of  the  kernels  will  take  place. 
Verification  means  that  the  kernels  have  been  technically  proven 
to  operate  as  documiented,  conforming  precisely  to  tne  model  and 
to  tne  specifications.  Verification  is  a tecnnical  quality 
control  process  that  ensures  tne  correct  functioning  of  the 
Kernel  . 

Formal  verification  of  the  suitability  and  capability  of  the 
kernel  based  system  to  enforce  the  security  rules  is  tne  target 
of  tne  technical  development  of  Project  Guardian.  before  tne 
resulting  system  can  be  used  in  an  operational  secure  site,  it 
must  oe  examined  and  certified  as  suitable  for  tne  use  intended. 
Certification  is  a process  where  tne  responsible  aooroving 
authority  decides  that  tne  system  will  indeed  oerforr,  its 
functions  as  specified,  that  tne  functions  performed  are 
appropriate  to  tne  use  at  hand,  and  that  the  system  adequately 
supports  the  security  requirements  of  the  user  agency.  Tne  Air 
force  intends  to  certify  tne  resulting  kernel  based  dultics 
system  for  test  and  evaluation  at  an  operational  Air  force 
Multics  installation. 

Tnis  document  addresses  the  requirements  for  protection  of  the 
Multics  security  kernel  and  the  Front-End  Processor  security 
kernel  in  tne  final  stages  of  development.  The  final  Kernel 
baseo  dultics  system  must  be  verified  and  certified  as  suitable 
for  operational  use,  so  the  kernels  must  oe  oroduced  and  verified 
in  a reliaole  environment.  Tne  characteristics  of  tne  required 
environm.ent  and  tne  crocedures  to  be  followed  by  tne  team  tnat 
produces  and  verifies  the  kernels  are  discussed  in  later  portions 
of  this  rebort. 


1.3  Required  Characteristics 

A secure  multilevel  rescurce  sharing  system  must  be  capable  of: 

o providing  comouting  service  to  a diverse  com.munity  of 
users  . 

o accommodating  users  with  several  different  levels  of 
clearance . 

o processing  and  storing  data  with  several  different  levels 
of  classification. 
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o enforcing  the  Departfrent  of  Defense  Information  Security 
Program  Regulations. 

o being  technically  verified  to  meet  the  above 
requirements. 

o being  formally  certified  as  adequate  for  the  specific 
application  intended.  ' 

Ihe  Air  Force  has  specified  tnat  an  acceptable  system  must  be 
secure  as  a result  of  the  functioning  of  the  hardvv-are  and 
software.  The  system  cannot  depend  on  secrecy  or  tne  hope  tnat 
an  antagonist  does  not  know  and  understand  tne  mechanism 
involved.  Tne  security  kernel  programs  are  tnus  to  be 
unclassified,  openly  distributed  to  the  public,  and  commercially 
avai lable . 

Tne  overall  goal  of  Project  Guardian  is  to  develop  a secure 
multilevel  resource  snaring  system,  that  meets  the  acove 
oojectives.  The  system  being  developed  is  based  on  the 
commercial ly  available  >iultics  system  of  Honeywell  Information 
Systems,  Inc.  A description  of  Project  Guardian,  and  plans  for 
tne  developm.ent  effort,  nas  been  published.  (1)  An  Operational 
Prototype  Secure  Multics  Demonstration  System  is  to  oe  produced 
as  the  final  output  of  Project  Guardian.  This  system  is  tnen  to 
oe  used  in  a test  and  evaluation  situation  at  an  operational  Air 
Force  Aultics  site.  Tnis  system  may  also  be  used  as  a reliaole 
source  for  transfer  of  the  system  to  otner  Aultics  sites. 

Tne  Operational  Prototype  Secure  Hultics  Demonstration  System  is 
expected  to  be  used  in  a real  situation,  processing  operational 
secure  (classified)  information.  Therefore,  it  is  essential  tnat 
tne  system  be  reliable,  verifiable,  and  certifiable  for  sucn  use. 
The  Statement  of  vVork  for  Project  Guardian  places  tne  following 
requirement  on  the  development  effort: 

Since  the  security  kernel  is  fundamental  to  tne 
protection  of  hignly  classified  data,  it  is  important 
tnat  tne  kernel  be  protected  from  sabotage  during  tne 
development  process.  One  example  of  sabotage  is  tne 
insertion  of  trapdoors  in  the  kernel  code.  Security 
procedures  snail  tnerefore  be  developed  for  tne  general 
protection  of  the  Kernel  during  tne  development 
process.  The  contractor  and  the  Air  Force  snail  worx 
together  to  identify  a set  of  procedures  describina  tne 
clearance  requirements  for  the  personnel  and  pnysical 
environment  involved  in  the  orotection,  developm.ent, 
and  certification  of  the  security  kernel. 


(1)  "i-iultics  " Security*  Integration  1 equirements"  , Honeywell 
Information  Systems,  Inc.,  to  be  publisned  as  an  ESD  Technical 
nepor  t . 
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The  Air  Force  has  further  advised  Koneyvvell  that  tne  security 
level  of  the  i<ernel  "software  verificat-ion  ef-fort-.ii-ay  -not  -h-ave  -to 
oe  as  hign  as  the  security  level  of  the  data  which  will  be 
processed  by  the  kernel  based  systsrr..  however,  it  is  necessary 
that  the  security  level  of  tne  verification  effort  oe  sufficient 
so  that  users  with  the  highest  clearance  will  entrust  their 
classified  data  to  tne  kernel.  Discussion  of  tne  aporooriate 
security  level  to  be  used  and  of  tne  procedures  to  be  follo.ved  in 
xernel  development  is  tne  subject  of  this  document. 


There  are  many  steps  in  the  development  of  a security  kernel  and 
many  documents  and  versions  involved.  Among  tne  documents  that 
must  be  protected  are  the  master  specifications  for  tne  kernels, 
the  representations  of  the  kernel  source  code,  and  the  ooject 
code  of  tne  kernel  itself.  Most  of  these  materials  will  exist  in 
both  macnine  readable  form  and  in  human  readable  fcrmi.  The 
threat  to  be  counteracted  is  any  form  of  unautnorized 
modification  of  any  of  these  master  reor esentations . There  is  no 
threat  of  disclosure,  since  it  is  the  intent  of  tne  project  to 
puolish  tne  results  openly. 

The  possible  mechanisms  for  unauthorized  modification  include  tne 
planting  of  Trojan  horse  procedures,  trapdoors,  or  loopnoles  in 
any  of  tne  materials  used  for  the  development  and  verification 
process.  Sucn  modifications  could  conceivably  be  placed  in  the 
material  at  any  level  witn  the  result  that  an  unknown  and 
undetected  vulnerability  might  be  built  into  the  system  for 
exploitation  at  some  later  date. 

Another  mechanism  for  unauthorized  miodi f ication  centers  on  tne 
Hardware  used  to  support  the  development  effort.  A modification, 
trapdoor,  or  bypass  mignt  be  installed  in  tne  computer  system.^ 
hardware  used  to  verify  the  kernel.  Such  a modification  might  be 
used  to  mask  tne  presence  of  a security  flaw,  preserving  it  for 
later  exploitation. 
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Tnus,  both  tne  hard'ware  system  used  for  tne  oevelopment  and  tne 
master  develooment  materials  need  to  be  protected  to  provide  tne 
degree  of  confidence  required  for  acceptance  of  tne  resulting 
kernel  based  Multics  system. 


1.4  Available  Tools 

There  are  a number  of  tools  and  procedures  available  to  provide 
tne  required  degree  of  protection.  Tnese  include  the  provisions 
of  tne  CoL  Information  Security  Program.,  tne  use  of  the  Access 
Isolation  .-lechanism  of  nultics,  and  configuration  management. 

Dxamination  of  tne  available  tools  and  crocedures  nas  led  to  tne 
conclusion  tnat  only  use  of  tne  DoD  Ir.for.mation  Security  Fro.grarr,, 
witn  its  attendent  ‘clearances,  classifications,  and  formally 
defined  procedures,  provides  tne  dearee  of  confidence  needed  to 
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ensure  acceptance  of  the  Kernel  based  system  for  its  intended 
use.  Only  the  Information  Security  Program  provides  a set  of 
enforceable  criteria  for  admittance  to  the  group  of  people 
authorized  to  create  and  modify  tne  master  materials.  Only  the 
Information  Security  Program  provides  the  set  of  formally  defined 
and  legally  enforceaole  procedures  for  the  handling  of  the  master 
material.  Finally,  only  the  Information  Security  Program 
provides  the  set  of  enforceable  legal  constraints  and  penalties 
to  ensure  compliance  witn  tne  procedures  to  De  follov,'ed. 

Tne  Access  Isolation  .'Jechanism  of  Wultics  provides  a set  of 
capabilities  that  can  be  used  to  support  the  requirements  of  tne 
Information  Security  Program.  The  Access  Isolation  Mechanism  is 
an  implementation  of  the  rules  of  the  Information  Security 
Program  within  the  multics  systenri,  providing  enforcem.ent  of  the 
security  rules  in  the  operation  of  Multics.  However,  the  Access 
Isolation  Mechanism  alone  is  not  sufficient  to  supply  tne 
protection  required.  It  can  enforce  tne  security  rules  only 
within  the  confines  of  the  Multics  system.  Ctner  mechanism, s are 
required  for  enforcement  outside  of  the  .Multics  system. 

Configuration  Management  is  a set  of  for.mal  disciplines  designed 
to  ensure  tnat  item.s  produced  under  its  control  conform  to  tne 
approved  specifications.  Tne  discipline  of  Conf iauration 
.Management  will  be  used  to  control  changes  and  modi  f ications  to 
the  kernels,  particularly  after  tne  close  of  the  verification 
pnase  of  activity.  (1) 

Tne  Information  Security  Program  orovides  three  levels  of 
protection,  CO.Mf  IDENTIAL,  SECRET,  and  TCP  SECRET.  Considerin'! 
tne  intended  use  of  tne  Operational  Prototype  Secure  i-.ultics 
De.nonstration  System,  the  use  of  the  TOP  SECRET  level  of 
protection  appears  necessary.  The  Air  Force  .may  desire  to 
increase  tne  level  of  protection  of  tne  material  by  assigning  one 
or  m.ore  special  access  categories  as  well  as  tne  designation  TCP 
SECRET.  This  does  not  initially  appear  to  oe  required. 

Tne  Information  Security  Program  is  described  and  specified  by  a 
number  of  Department  of  Defense,  and  Air  Force  publications.  Tne 
principal  publications  used  to  specify  this  program  are: 


(1)  "Configuration  .'la’nag  ament*  Plan',  Honeywell  Information 
Syste.ms,  Inc.,  ESL-TR-75-354 . 
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Information  Security  Program  Regulation 

Industrial  Security  .Manual  for  Safeguarding 
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Information  Security  Program 
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Special  Considerations 


2.1  Tne  Protection  Probleni 

Tne  master  material  to  oe  protected.  from  unautnorizec 
•Tiodif  ication  includes  ootn  human  and  macnine  readable 
representations  of  information.  It  is  essential  to  tne  integrity 
of  tne  verification  ana  certification  process  that  tnere  be  a 
guaranteed  one-to-one  correspondence  between  tne  numan  readable 
and  the  macnine  readaole  represen tat  ion  of  a particular  piece  of 
information.  Only  tne  master  copies  of  tne  material  need  such 
protection.  One  of  the  requirements  of  the  project  (no 
depenaence  on  secrecy)  m.eans  that  unauthorized  disclosure  of  tne 
material  is  no  threat  and  requires  no  protection.  The  .master 
materials  must  be  protected  from  unauthorized  alteration  at  the 
security  level  desired  for  the  final  Kernel  based  syste.m.  In 
dultics  access  control  terms,  tne  proble.m  is  one  of  giving  read 
access  to  everyone  while  restricting  «rite  and  modify  access  to  a 
very  s.xiall  and  select  group.  The  difficulty  co.mes  from  tne  many 
ways  that  a sufficiently  motivated  malicious  person  .may  find  to 
suovett  tne  controls  imposed. 

Lse  of  tne  procedures  of  the  Infor.mation  Security  Progra.Ti 
provides  tne  degree  and  Kind  of  protection  needed,  cut  such  use 
also  provides  protection  that  is  not  needed.  Tne  In for.m.ation 
Security  Program  was  designee  to  protect  sensitive  material  from 
unautnorized  disclosure  as  well  as  to  protect  it  from 
unauthorized  alteration.  This  project  does  not  require 
protection  from  disclosure,  so  .many  of  the  procedures  of  tne 
information  Security  frog  ram  are  nor  required.  In  particular, 
tnere  is  no  require.ment  to  shield  tne  comouter  hardware  to 
prevent  electr c.ma unetic  radiation. 


2.2  Use  of  Security  Classification 

The  Infor.mation  Security  Frogra.m  encourages  classification  of  tne 
least  material  possible  at  the  lowest  level  oractical . The 
lowest  acceptaole  level  appears  to  be  TOP  SLCfST  since  the 
resulting  Kernel  oased  systemi  may  well  find  its  way  into  tne  most 
sensitive  usage  areas  of  the  government.  Tne  least  material  to 
be  classified  appears  to  be  the  master  copies  of  the  items  used 
to  specify,  code,  and  run  the  fiultics  kernel  and  tne  front  Ena 
irocessor  Kernel. 

ine  .material  to  be  protected  will  be  selected  and  specified  oy 
agreement  cetween  tne  Air  Force  and  i;oneyweil.  It  is  likely  tnat 
tne  source  progra.ms  (written  in  tne  syste.m  development  language) 
tor  ootn  tne  .'lultics  security  Kernel  and  the  Front  End  Processor 
security  Kernel  will  oe  protected.  Similarly,  tne  ooject  cooe 
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for  the  two  xernels  requires  protection.  Otner  items  that  may  be 
consiaereci  for  protection  include  both  tne  macnine  readable  and 
numan  readaole  representations  of  tne  matnematical  moael,  tne  top 
level  kernel  specification,  the  system  specif ication , tne  kernel 
development  specifications,  and  the  kernel  product 
speci f ications . 

The  material  is  eligible  for  tne  protection  of  classification 
under  the  Information  Security  Program,  CoC  52C0.1-R.  Paraarapn 
2-303,  Specific  Classifying  Criteria,  lists  two  items  met  oy 
Project  Guardian  as  criteria  for  classification.  Tnese  are: 

(a)  The  information  provides  the  United  States,  in 
comparison  with  other  nations,  with  a scientific, 
engineering,  tecnnical,  operational,  intelligence, 
strategic  or  tactical  advantage  directly  related 
to  the  national  security. 

(e)  There  is  sound  reason  to  believe  tnat  knowledge  of 
the  information  would:  (a)  provide  a foreign 

nation  with  an  insignt  into  tne  war  potential  or 
tne  war  or  defense  plans  or  posture  of  the  United 
States;  (o)  allow  a foreign  nation  to  develop, 
improve  or  refine  a similar  item  of  war  potential; 

(c)  provide  a foreign  nation  witn  a base  upon 
wnicn  to  develop  effective  counter  .measures;  (dj 
weaken  or  nullify  the  effectiveness  of  a defense 
or  military  plan,  operation,  project  or  activity 
wnicn  is  vital  to  tne  national  security. 

The  possession  of  a certifiable  secure  multilevel  system  will 
provide  the  United  States  with  an  operational  advantage ’ and 
marKedly  reduce  the  expense  of  secure  computing. 

Access  to  tne  protected  master  representations  could  provide  a 
foreign  power  witn  a base  for  effective  countermeasures  tnrouTh 
saootage  and  unautnorized  m.odi f ica tion  to-  tne  Kernels.  Tnis 
could  weaken  or  nullify  tne  effectiveness  of  tne  kernel  based 
I'iultics  system  as  a means  of  protecting  military  inf or.m.a ticn 
wnicn  is  vital  to  the  national  security. 

rioneywell  recommends  use  of  the  Information  Security  Program  and 
classification  to  protect  the  kernels  under  final  development  and 
verification.  Only  tne  Air  Force  can  maKe  tne  determination  tnat 
tnis  degree  of  crotection  is  warranted.  Ihe  for.mal  requirements 
for  sucn  determination  are  outlined  in  tne  referenced  regulations 
(UoD  52C0.1-P  and  AIR  2C5-1)  in  Paraqrapn  2-4C3,  "Fesearch, 
development.  Test  and  evaluation  Progra.ms''  . 


o 
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SECTION  3 


Proposed  Procedures 


3.1  Protected  Environitent 

It  is  r ecom.T.ended  tnat  a protected  enviror.iTient  be  established  for 
tne  performance  of  the  final  security  kernel  development, 
verification,  and  demonstration.  Tnis  protected  environ.ment 
snail  oe  as  appropriate  for  material  and  activities  at  tne  ToF 
SECkET  classic ication . Variations  from  tne  reauirements  of  a 

standard  TOP  SECRET  closed  area  will  oe  discussed  oelow  in 
conjunction  with  tne  components  of  the  environment  and  the 
personnel  involved. 


3.2  Verification  Team 

A standard  part  of  tne  Information  Security  Program  is  tne 
restriction  of  access  to  tne  minimum  numoer  of  people  and  tne 
granting  of  security  clearances  to  only  tnose  people  who  require 
access  to  tne  material.  In  accordance  witn  this  well  establisned 
principle,  it  is  recommended  that  a Verification  Team  ce 
estaalisned.  Tne  Verification  Team  snail  consist  of  tne  smallest 
number  of  people  practical  to  perform  tne  functions  required  in 
tne  development,  verification,  and  demonstration  of  tne 
operational  trototype  Secure  Nultics  Demonstration  System. 

All  members  of  tne  Verification  Team  must  possess  security 
clearances  of  at  least  the  protection  level  chosen  for  the 
development.  xithin  tne  Verification  Team,  only  those  witn 
specific  need  for  write  and  modify  access  on  tne  master  materials 
snail  oe  given  need-to-.<now  access.  N'eed-to-i<now  access  shall  oe 
restricted  to  tne  specific  master  material  concerned  and  ne  valid 
cniy  for  tne  time  period  required  to  oerform  tne  specific  tasK. 

v^ne  memoer  of  tne  Verification  Team,  shall  oe  designated  as  System 
security  Acministr ator  witn  respons ioil i ty  for  granting, 
monitoring,  and  removing  need-to-know  access  privileges. 

Tne  support  personnel  at  tne  site  must  also  posess  adequate 
security  clearances.  These  personnel  include  machine  operators, 
clerical  support  personnel,  computer  maintenance  engineers,  and 
ouilding  .maintenance  personnel. 


3. 3  Fnysical  Site 

Tne  pnysical  site  used  for  tne  protected  portion  of  the  Kernel 
development  effort  shall  oe  protected  at  tna  level  selected  for 
tne  development . Closed  Areas  snail  be  established  for  tne 
office  soace  for  tne  Verification  Team,  for  the  orotected 
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terr.^ir.als  used  to  access  the  computer,  for  tne  computer  system 
used,  and  for  the  storage  of  the  protected  master  material. 
Provisions  of  tne  Information  Security  Proqra.m,  as  detailed  in 
the  Industrial  Security  hanual  for  Safeguarding  Classified 
Information  (LoD  5220 . 22-h)  snail  be  followed  in  preparing  tnese 
areas.  Specific  v/aivers  of  requirements  may  oe  requested  to 
avoid  unnecessary  operational  restrictions  and  expense.  Since 
tne  Information  Security  Program  was  designed  orimarily  for 
prevention  of  disclosure  of  information,  tnere  will  be  numerous 
requirements  tnat  provide  protection  from  tnreats  wnich  are  not 
of  concern  nere. 

'ine  worKing  area  for  the  Verification  Team  snail  be  designated  as 
a Closed  Area  as  defined  oy  Paragraoh  34,  "Area  Controls",  and 
Appendix  V,  "Guidelines  for  tne  Pnysical  Construction  of  Closed 
Areas",  of  the  Industrial  Security  Manual.  The  puroose  of  tnis 
designation  is  to  reduce  tne  opportunity  for  unautnorized 
individuals  to  acces;  the  protected  master  materials  and  to 
influence  tne  contents  of  the  materials. 

Tne  computer  nardware  used  to  provide  ilultics  service  and  to 
support  tne  demonstration  system  snail  oe  nousec  in  a Closed 
rttea.  This  is  to  ensure  that  only  individuals  witn  the  proper 
level  of  clearance,  or  individuals  escortea  by  personnel  witn  tne 
proper  clearance,  can  gain  access  to  tne  nardware  used  for  tne 
project.  The  tnreat  of  unautnorized  modification  of  the  naraware 
system  used  is  countered  oy  tnis  designation.  Tnis  Closed  Area 
may  not  require  the  full  protection  specified  for  tne  chosen 
level  of  protection,  since  unauthorized  disclosure  of  information 
13  not  a tnreat. 

A Closed  Area  shall  be  estaolisnea  to  nouse  tne  terminals  used  oy 
tne  Verification  Team  to  access  tne  computer  nardware.  Tnese 
terminals  snail  oe  attacned  to  tne  computer  by  hardwired  lines 
wnicn  are  protected  at  the  same  level  as  the  rest  of  tne  system. 

A storage  facility  for  the  protected  master  materials  shall  be 
establisned.  This  facility  must  meet  tne  requirements  of 
Paragrapn  14,  "Storage",  and  Appendix  IV,  "Outline  Construction 
specifications  for  Storage  Vaults",  of  tne  Industrial  Security 
ihanual.  cotn  human  readable  (paper)  and  macnine  readable 
(magnetic  tapes  or  disKS)  representations  of  the  protected  master 
copies  must  be  kept  in  tne  storage  facility.  Tne  storage 
facility  will  oe  used  to  nold  tne  protected  master  copies  of  the 
material  wnen  they  are  not  in  use.  The  storage  facility 
completes  tne  physical  protection  capability  required  for 
protection  of  tne  master  material. 
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3.4  Operating  Procedures 

Detailed  operating  procedures  will  be  establisned  for  tne  portion 
of  tne  effort  tnat  is  to  oe  perforiiied  under  protection.  Tnese 
procedures  will  be  based  upon  the  requirements  of  tne  Information 
Security  Program  as  detailed  in  the  Industrial  Security  lianual 
ana  applicaole  Air  Force  Kegulations.  Tne  procedures  will  be 
administered  oy  tne  oesignated  System  security  Administrator . 
Tne  detailed  operating  proceoures  will  oe  based  upon  tnese 
guidelines: 

1.  The  master  copy  of  eacn  item  is  protected  by  beina 
classified  at  the  selected  level,  probably  TOP  SLCAET. 

2.  Master  copies  ate  matKed  in  distinctive  fasnion  in 
accordance  with  the  rules  given  in  the  Information 
Security  Program  and  related  Air  force  Regulations. 

3.  All  otner  representations  and  copies  of  the  material  are 
not  protected  and  are  designated  UNCLASSIFIED.  no 
special  marKings  are  required. 

4.  The  master  copy  of  an  item  is  Kept  under  strict 
accountability  control.  It  is  serial  numoered  and 
registered  upon  creation  and  is  loqged  in  a master 
control  station.  All  access  to  tne  master  copy  is 
recorded  at  the  control  station. 

5.  Superceded  master  copies  will  oe  destroyed  according  to 
tne  selected  level  of  protection.  A minimum  numoer  .Q.f 
nistory  copies,  all  clearly  designated  as  such,  will  be 
miaintained  . 

6.  Only  tnose  members  of  the  Verification  Team  wno  have 
■'need-to-Know"  granted  oy  tne  System  Security 
Administrator  will  have  access  to  write  on  or  modify  tne 
master  copy. 

7.  Only  tnose  members  of  tne  Verification  Team  wno  nave 
"need-to-.Know"  granted  by  tne  System  Security 
Administrator  will  be  allowed  to  generate  a new  master 
copy.  Generation  includes  assemcly,  compilation, 
linking*,  printing,  or  macnine  editing. 

8.  The  System  Security  Administrator  will  grant 
" need-to-Know"  access  only  to  tnose  witn  legitimate 
requirements  for  such  access  and  only  for  tne  time 
periods  necessary  for  the  completion  of  tne  functions. 

9.  All  other  activities  of  tne  Verification  Team  and  tne 
uncleared  system  developers  will  be  carried  out  using 
unprotected  copies  of  tne  material. 
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10.  The  act  of  transferring  information  from  an  unprotected 
source  to  tne  protected  master  copy  will  oe  done  witn 
tne  full  knowledge  and  responsioility  tnat  tnis  is  the 
critical  act  in  the  entire  process.  Appropriate 
safeguards,  including  distribution  of  effort,  cnecking, 
and  personal  signature  acKnowledgement  will  oe  applied. 


3.5  XarKing  the  ilaster  Cooies 

The  master  copy  of  eacn  item  is  protected  by  classification  wnile 
otner,  nonmaster  copies  are  unclassified.  Ine  master  cooy  must 
oe  distinctly  marked  in  accordance  with  the  requirements  of  the 
Industrial  Security  I'ianual  for  material  of  tne  selected  level, 
cotn  human  readable  representations  (printed  on  paper)  and 
macnine  readable  representations  (held  in  tne  Sul  tics  virtual 
memory  or  residing  on  magnetic  tape  or  disk)  must  be  marked. 

Paper  copies  snail  oe  stamped  witn  the  classification  level  on 
tne  front  and  oacK . Lacn  master  cooy  produced  snail  have  a 
serial  number  assigned  to  it.  A Data  «ccountaoil  i ty  rorm  »^ill 
also  be  generated  for  use  as  a receict  wnen  the  master  copy  is 
accessec  oy  anyone.  The  creation,  access,  and  disposition  of 
eacn  master  copy  snail  be  recorded  at  a .aster  Control  Station. 
Capaoilities  of  tne  dultics  Access  Isolation  .lecnanism  (Alii)  may 
oe  used  to  mark  tne  classification  on  the  pages  and  to  generate 
tne  L'ata  Accountaoil i ty  Eorm  wnen  the  docu.'nent  is  printed. 

1‘iachine  readable  copies  snail  be  bandied  in  a manner  similar  to 
that  useo  for  paper  copies.  Magnetic  media  containing 
representations  of  a master  copy  snali  oe  marxed  on  tne  m.edia  and 
on  tne  container  witn  a label  snowing  tne  level  of  protection  and 
a serial  numoer  for  the  media.  Data  Accountability  Forms  and 
Aaster  Control  Station  logging  will  be  used  for  the  control  of 
magnetic  media.  i 

. rtnile  a representation  of  a master  copy  is  residing  in  tne 

virtual  memory  of  Multics  , tne  system  shall  ba  operated  in 
accordance  with  tne  regulations  of  the  Industrial  Security 
Aanual.  The  system  snail  be  operated  as  a protected  system 
wnenever  it  contains  a representation  of  tne  protected  master 
Kernel  and  it  is  expected  that  this  representation  will  oe 
written  out  ana  reused  as  a representation  of  tne  master. 


3.0  Use  of  the  dultics  Access  Isolation  Mechanism 

Tne  rtccess  Isolation  decnanism  (AIh)  provides  a computer  cased 
implementation  of  tne  CoD  Information  Security  Program,  out  is 
not  a full  Kernel  cased  system,  and  so  is  not  certifiaole  to  tne 
level  desired  for  tais  program.  Air.  does  provide  a large  set  of 
control  capabilities  to  augment  tne  protec tien  of  tne  master 
copies.  Tne  access  Isolation  .-iecnanis.r.  can  oe  used  on  Multics  to 
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provide  the  desired  protection  and  isolation  of  machine  readable 
representations  of  the  master  materials. 


AIw  provides  sensitivity  levels,  special  access  cateqories,  and 
neea -to-know  controls  that  are  under  tne  control  of  the  System 
Security  Administrator.  Tne  System  Security  Administrator  can 
limit  the  access  capabilities  of  persons,  projects,  and  terminal 
devices.  An  Audit  Log  is  maintained  tnat  records  selected  items 
of  security  interest  as  tne  system  is  used.  AIi"-  also  provides 
for  tne  automatic  marking  of  the  sensitivity  level  on  orinter 
output  and  for  tne  generation  of  a Data  Accountability  Form  for 
eacn  item  of  protected  information  printea. 

Tne  System  Security  Administrator  can  designate  a protected  copy 
of  eacn  service  program  tnat  will  be  used  in  tne  editing  or 
creation  of  a master  copy.  For  example,  a particular  copy  of  tne 
compiler  can  be  designated  as  protected,  with  access  for  its  use 
restricted,  to  those  members  of  the  Verification  Team  witn 
‘‘ need-to-xnow"  . All  compilations  of  master  material  can  tnen  be 
done  using  tnis  protected  version  of  the  compiler.  This  will 
reduce  the  possioility  of  unknowns  being  introduced  oy  way  of 
saootage  of  the  service  programs.  Service  programs  which  are 
candidates  for  such  protection  include  tne  text  editor,  system 
programming  language  compiler,  linker,  and  the  debugging  tools 
used  . 


3.7  Accountability  and  Control 

The  Information  Security  Program  (DoD  5200. 1-R)  and  the  Air  force 
Regulation  tnat  expands  it  (AfR  205-1)  detail  tne  nandlinq 
requirements  for  material  protected  at  tne  TOP  SLCRET  level. 
Paragraph  7-3C0  in  both  references  describes  tne  requirement  for 
a Top  Secret  Control  Officer  (TSCO) , who  is  tne  System  Security 
Administrator  referenced  earlier.  The  piaster  Control  Station 
uses  a log  called  the  "Top  Secret  Register"  for  accountabi 1 i ty 
registration  and  document  control. 


It  is  recommended  that  tne  procedures  given  in  Paraqrapn  7-300  be 
followed  for  tnis  pnase  of  tne  development  effort. 


3.8  Transfer  to  Other  Sites 

v'<nen  it  is  desired  to  transfer  tne  Operational  Prototype  Secure 
Multics  Demonstration  System  to  another  physical  site,  tne  need 
lor  protection  remains.  It  is  recommended  tnat  a protected  copy 
of  tne  Kernels  oe  produced  and  transferreu  to  tne  destination  as 

)a  classified  shipment.  Once  tne  new  kernel  is  safely  «itnin  tne 
destination,  it  may  oe  declassified  if  desired.  Tne  rationale 
for  tnis  metnoo  of  transfer  is  to  extend  protection  from  tne 
protected  source  Kernel  to  tne  new  destination  Kernel.  'ine 
protection  subsequently  given  tne  new  Kernel  is  tne  orerogative 
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of  tne  usinq  organization.  It  will  depend  on  tne  uas  made  of  tne 
i-iultics  system  at  tne  new  site  and  on  the  security  environment  at 
tne  new  site. 


[ 
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AtPLtiDIX  A 

Air  Force  Electronic  System  Division  Comiiients 


Section  1.2  --  Incorporate  reference  to  other  Honeywell,  Mitre 
and  Air  Force  documents  wbicn  describe  the  efforts  and  results 
alluded  to  by  this  section. 

Page  6,  line-11  (eleventh  line  from  bottom  of  pane) 
Unclassified  is  also  a security  level. 

Page  15  — Add  a conclusion  to  tnis  report. 


